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AUTOMATIC UPDATE OF CAMERA 
FIRMWARE 

FIELD OF THE INVENTION 

The present invention relates to the Geld of imaging. More 
particularly, this invention relates to updating firmware 
between an imaging device and a host system. 

BACKGROUND OF THE INVENTION 

Imaging devices, such as cameras, typically store still or 
moving (video) image information on film, video tape, or 
other media. Digital cameras capture image information in 
digital format and store the image informatioD in memory, 
such as a flash memory, or on other digital storage media. 
The digital image information can be downloaded to a host 
system, such as a personal computer. The image information 
can then be manipulated by rotating the image, cropping the 
image, or otherwise altering the image with software appli- 
cations residing on the host system. 

The imaging device includes firmware that allows the 
imaging device to communicate with software on the host 
system. The firmware includes instructions for performing 
various functions. For example, the firmware may be used to 
determine the exposure of an image, sense color in a 
particular manner, compress image data, conserve power, 
perform self tests, and/or specify accessing and formatting 
protocols to the storage medium on the camera. 

Oftentimes, it is desirable to upgrade either the host 
software and/or the camera firmware with a new release of 
software or firmware. A common method for upgrading 
software is through the use of a patch, or service pack 
upgrade. This method consists of distributing a set of 
programs via floppy disk, CD-ROM, or Worldwide Web to 
the host machine. The service pack, when run, modifies the 
components of the host software that need updating. 

Updating the firmware is more problematic. This process 
is typically performed manually by a user. It may involve 
running an executable program, then resetting the imaging 
device. Manual updating of the firmware is inconvenient, 
and may lead to errors caused by incompatible versions of 
firmware and host system software. 

SUMMARY OF THE PRESENT INVENTION 

A method of updating firmware on an imaging device 
coupled to a host system is disclosed. The host system 
detects that the firmware on the imaging device is incom- 
patible with a configuration of the host system. In response 
to detecting the incompatibility, an updated firmware image 
is transferred from the host system to the imaging device. In 
one embodiment, the updated firmware image is an older 
version of firmware than the one that is replaced. 

Other features, and advantages of ihe present invention 
will be apparent from the accompanying drawings and firom 
the detailed description that follows below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a representation of an imaging device that 
is attachable to a host system. 

FIG, 2 shows one embodiment of the flow of information 
among the components of the host system when the imaging 
device 10 is first connected to the host system 20. 

FIG. 3 shows one embodiment of the flow of information 
among the components of the host system after the host 
application software 60 has been initiated. 
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FIG. 4 shows one embodiment of the polling initialization 
process. 

FIG. 5 shows an embodiment of the polling process 
between the camera API 62 and the host applications soft- 
5 ware 60. 

FIG. 6 shows a flowchart of one embodiment of the 
process of checking whether a compatible imaging device is 
connected to the host system. 

FIG. 7 shows a flowchart of one embodiment of updating 
the firmware. 

FIG. 8 shows one embodiment of a state transition dia- 
gram of the firmware boot process. 

FIG. 9 shows a diagram of an exemplary nonvolatile 
15 memory 400 which stores the firmware. 

FIG. 10 shows a flowchart of one embodiment of the 
process of initializing the host application software to estab- 
lish a communication with a camera. 

FIG. 11 shows a flowchart of one embodiment of the 
2^ process of detecting that an imaging device such as a camera 
is attached to a host system. 

DETAILED DESCRIPTION 

A metho d of jiEdating firmware between an im aging 
device andTj^oSt^systein^l^ disclosed . 1 he nrmware mcludes 
instructions wffich-are-useii to control an embedded system, 
such as an imaging device. In one eml ^iment, t hefirmware 
updat e is perform ed au tomatically upon connectin g the 
imap,in ^"dEVicc to The host system . 1 his^mplities operation 
fo r the user while ensuri ng compatibility between the imag- 
ing devioe^aod t he hostloftwa re. The firmware update may 
provide(J^^ fixes, enhancements to algorithms, updated 
color sensing, updated compression, new protocols for 
accessing and formatting the storage medium, and so forth. 
As will become clear, the automatic firmware update is 
particularly useful when multiple a imaging devices with 
different versions of firmware are used with host systems 
that have different versions of software. 

The following description describes the firmware update 
in the context of a system that transfers image information 
between the image device and the host system automaticaUy 
upon coupling the image device to the host system. 
However, the firmware update is not limited to such a 
^5 system. 

The imaging device may be an image capture device, such 
as a camerac Alternatively, the techniques disclosed can be 
used with any f^pvire. that i s capable of storing^ ima ge 
i nformation . The host system may be anv system which is 

50 capable of manipu lating image informa tion. For example, 
the host system may b e a personal computer such^a^ , an 
IBM-compa tible^ personal ^ computer_Junnin g on an Intel 
Pentiurri® or Pentium® II processor. Jlowg;iier,„tbs host 
SYi ^;n■Cftl^4aUemativ e^y be a printq^, plotter^ fa?^ machine, 

55 display dcyice> _Qrc.stjOEag.e,desdc^ 

For purposes of clarity, the following description is writ- 
ten in terms of the imaging capture device being a camera 
and the host system being a computer. It should be under- 
stood that other imaging devices and host systems may be 

60 employed. 

FIG. 1 shows a representation of an imaging device 10 
t hat is attachable to a host system 20. In one embo diment, 
the imaging device 10 is attached j aa-a-cabLle_ 22 to a po rt 26 
of the host system 20. The imaging devi ce 1 0 is prefe rably 
65 coupled to the host system"20'usi ng a dat aJian sfer protoc ol 
that suppo rte a hiab data transfer rate . In one embodiment, 
the imaging device 10 is coupled to the host system 20 via 
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a Universal Serial Bus (USB) connection. The USB coo- decompression and/or color correction on the images. Fur- 

nection provides for a data transfer rate of up to 12 Mb/s. thennore, the host application software 60 may perform 

Other comiections and data transfer protocols may aheroa- rotation, cropping, and other image manipulation functions, 

lively be used, such as the 1394 protocol. (More information Some operating systems, such as Windows 98 allow 

on USB can be obtained from the World Wide Web at the 5 specific events to cause software applications to be 

URL http://www.usb.org/. The 1394 standard is maintained launched. For example, the camera driver 44 can be set up 

and distributed by the Institute of Electrical and Electronic with registered events such as "connection detected with 

Engineers. Firewire, one implementation of 1394, is defined camera" or "shutter button on camera is pushed." Thus, an 

by IEEE Standard 1394-1995.) operating system can be set up to automatically launch an 

FIGS^2 and.3 are embodiments showing the relationship lO application such as the host application software 60 when 

and^messaging between components of the host system 20 the camera 10 is attached. 

andimagngdevice (camera) 107FIG72sh"6ws^neembodi- lo one embodiment, if the camera driver 44 or the host 

ment of the flow of information among the components of appHcation software 60 is not installed on the host system 20 

the host system when the imaging device 10 is first con- when the camera 10 is attached to the host system 20, then 

nected to the host system 20. The host system 20 includes an 15 the user is requested to provide the camera driver 44 and/or 

operating system (0/S) 40 and host application software 60. host application software 60 for the device that has been 
The host system 20 detects when an imaging device suchlasTy attached to the port 26. Once the installation has been 

a camera 10 is attached to the host system 20. In one completed, the process proceeds as previously described, 

embodiment, the oB crating system 40 dgt CQts whether a FIG. 3 shows one embodiment of the flow of information 

camcfTIOlsat tachS^to the system by^go5i ng)t1ie port 2 6. 20 among the components of the host system after the host 

A po"rt driver 42"may^e usedlo proi^de aB'ffif^rtace t?etween application software 60 has been initiated. In this embodi- 

the operating system 40 and the port 26. In one embodiment, ment, after being loaded, the host application software 60 
the port 26 is a USB port and the port driver is a USB driver. 23 creates and initializes a camera Applications Programming 
The operating system may be one of a variety of different^ Interface (API) 62 as indicated by arrow (4). The camera 

operating systems. In one embodiment, the operaUng system ^5 API 62 may perform its task in a background thread. In this 

is a Windows* operating system, such as Windows* 95, or manner, the host application software 60 need not wait for 

Windows* 98 made by Microsoft Corporation. Windows 98 camera API 62 to complete before performing other 

includes hooks which allow the polling of ports. Other tasks. In one embodiment, the camera API 62 is a COM 

operating systems may be modified to provide for such object which loads a dynamic link library (DLL) 64 as 

polling. The poUing is preferably performed in the back- 30 shown by arrows (5). The DLL may be 0/W dependent. The 

ground so that the user need not be aware that it is being camera API 62 communicates to the operating system 40 via 

performed. Alternatively, host appUcation software 60 can ihe DLL 64. (In another embodiment, the camera API 62 

perfomi the polling of the port 26. However, poUing by the incorporates the DLL 64.) The operating system 40 in turn 

operating system 40 (instead of by host application software communicates with the camera 10 via the camera driver 44 

60) hasa^p^rmance-advaotage, since the operating system 35 and the port driver 42 as shown by arrows (6). 

is aheady set up for polling various activities, such as FIG. 4 shows one embodiment of the polHng initiahzation 

keyboard pushes, mouse movements, and so forth. For the process. The polhng initialization process begins with the 

purposes of illustration, the following description assumes operating system opening the host application software. The 

that the operating system does the poUing. A person skiUed host application software 60 then creates and initializes a 

in the art can make the modifications to allow an appUcation camera API 62. In one embodiment, the host appHcation 

to do the polling. software 60 adds itself to the camera APFs callback list, so 

* Third-party marks and brands arc the property of tbcii respective owners. that the hos t application software 60 will he not ifled wh en 

When a camera 10 is connected lo the port 26 of the host the camera API is successful in the polling proc^ . 

system 20, the port driver 42 signals the operating system 40 In one embodiment, the camera API upon initialization 

that the camera has been attached to the host system 20. This 45 resets its internal variables, loads a DLL, and creates and 

is illustrated by the arrow marked (1) shown in FIG. 1. The starts a background thread. The camera API then inserts a 

operating system 40 identifies the device as a camera and message into the background threaded queue that tries to 

loads the corresponding software driver 44 into memory as open the camera driver. (A driver is "opened" by cstablish- 

illustrated by the arrow (2). In one embodiment, the oper- ing a connection between the camera API and the driver.) In 

ating system 40_interrogates the camera 10 to get an iden- 50 one embodiment, the camera driver is only opened when a 

tifier. The operating system 40 loads the software~anV5r44 camera is attached: If the camera driver cannot be opened, 

corresponding to the identifier. In this example, a camera then a camera is not attached to the host system. If a camera 

driver 44 is loaded by the operating system 40. driver can be opened, then a camera is attached. In one 

The operating system 40 then loads one or more software embodiment, the camera API 44 attempts to open the camera 

applications corresponding to the camera. In one embodi- 55 driver every half a second. 

ment, the operating system allows software applications to FIG. 5 shows an embodiment of the polling process 

be registered. Upon meeting a predetermined condition between the camera API 62 and the host_a ppli cation s oft- 

(such as a camera with a particular identifier being detected), ware 60. In this embodiment, the camera API 62 attempts to 

the registered host application sofhvare is loaded. In this open thecamera driver (CM_SIGNAL_STArUS). When it 

case, the host application software 60 (for the camera) is 60 is successful at opening the camera driver, the camera API 

loaded as shown by the arrow (3), In one embodiment, the closes the camera driver, and notifies the applications in its 

camera driver 44 signals the operating system 40 to initiate callback queue. Since the host application software 60 is in 

the host application software 60. The host application soft- the callback queue of the camera API, it is notified that a 

ware 60 initiates the transfer of image information between camera has been detected. 

the image cfevice (camera) 10 and the host system 20. The 65 In this embodiment, the host application software 60 

host application software 60 may also process images. For re-opens the camera driver 44 by signaling the camera API 

example, the host application software 60 can perform 62 to open the camera driver 44 and check for a compatible 
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camera (CM_OPEN_DRIVER). The host application soft- 
ware 60 can then send various commands to the camera 10 
via the camera API 62 (and the operating system 40 and 
drivers 44 and 42). For example, the host application soft- 
ware 60 can request the number of images stored in the 
camera (CM_GET__NO_OF_JMAGES). The host appli- 
cation software 60 can request a list of the names of the 
images and the image sizes (CM_GET_IMAGE_LIST), 
or it can request a particular image (CM_GET__IMAGE_ 
BY_NAME). 

In one embodiment, the camera API 62 checks whether a 
compatible imaging device is connected to the host system, 
and automatically updates the firmware on the imaging 
device, if necessary. The automatic firmware update may be 
disabled or enabled as a factory setting by the manufacturer, 
or it may be alterable by the user. 

FIG. 6 shows a flowchart of one embodiment of the 
process of checking whether a compatible imaging device is 
connected to the host system. In one embodiment, this 
process is performed by the camera API 62. As previously 
mentioned, the camera API 62 is created and initialized by 
the host application software 60 as shown at block 100. The 
camera API 62 loads a DLL that may be operating system 
dependent at block 102, and the host application software 60 
issues an open command to the camera API 62 at block 104. 
The camera API in response, opens the camera driver 62 via 
the DLL 64, as shown in block 106. 

At block 108, the camera API 62 issues a command to the 
camera to fetch the camera interface number. In one embodi- 
ment, a unique camera interface number is assigned to a set 
of commands that the camera supports. 

Operation continues at decision block 110. The interface 
number from the camera is compared with an interface table 
in the camera API 62. If the interface number is not stored 
in the camera API 62 interface table, then the camera API 62 
closes the camera driver and signals to the host application 
software that the camera is incompatible, as shown at blocks 
112 and 114. The camera API is not able to communicate 
with the camera because the commands that the camera 
supports is not known. 

_At_ block 110, if the interface number from the camer a is 
stored in the interface table of the camera API 62, then t he 
camera API 62 issues a command to the came ra to fetch a 
h ardware version number^ as shown at blo ck "l2u" ' 

At block 130, the hardware version number from the 
camera is compared with a hardware table stored in the 
camera API 62. If the hardwarc-vcrsion-number-frp jn the 
c amera is not stored .in.thc_h ardwarc'tab le.Q£.the.camcra API 
62, then the camera API 62 is unable to check for an updat e . 
The camera API 62 si gnals th e host apphcation software that 
the camera is o pen Joc-access,-as.shown.at.blockJ.3!2.jrhc 
camera API ^2^ is able Jo .conirnunicate w ith tbe^ camcra 
b'ecaiise its interface is compatible, bu tiLdo es not u p date the 
fi rmware because it docs not reg ogoizcth e. hardware con - 
figuration . 

At block^l30T _if the ha rdw are versi on mimberjrpm the 
cam^rajs_^Qtedia the hardware table of the camera API 62, 
then operat ion proceeds to block 140. At block -l-4Q^_ the 
camera APTis sues a comman d toJhe-C ameta to retur n the 
firmware version numb er. 

Operation proceeds to block 150. If the firmware version 
number is not jifferent^ than^thaLstored-with in the ca mera 
API 62, thenjbe^ca mcra bas up dated^ firmware^ jready. The 
camec a API 62 si g nals the^ hQst.applic_ ation softwa re that the 
camera is open Jo i^ access. 

TtThe'fiTmwa re version number is differeat than th at stored 
in the cam era API 62, then o peration conti aues .at block 16 0. 



If the manufacturer has disabled the firmware updates, then 
the camera API 62 does not perform a firmware update and 
signals the host application software that the camera is open 
for access. For example, the manufacturer may set a bit in a 
5 register of the camera disabling firmware updates. Although 
the installed firmware may not be the latest version, the 
installed firmware is still able to perform with the host 
software as long as the interface and hardware are compat- 
ible. 

10 At block 170, a check is made whether the update has 
been tried before and failed. In one embodiment, a prede- 
termined number of update tries is performed. If the update 
has been tried before and failed, then the camera API 62 
signals to the host application software that the upgrade 

15 failed, and that the camera is open for access, as shown at 
block 172. 

At block 170, if the update has not been tried before,%en 
the flowchart proceeds with the firmware update process, as 
shown in FIG. 7. 

20 FIG. 7 shows a flowchart of one embodiment of updating 
the firmware. . At b lQck^2Q0^th^ camera APL Jransfcrs_an>z^ 
updated fir mware image to the camera.. In o ne embodiment AT- 
t he camera A PI sepds^ download firmware com m and tojh e 
camera,^o,that_thfc,firmware_will^be.rca dv to receive a ne w 

25 JSxmware image, JThe u pdated firmware imag e is then trans- 
ferredjr o m the host system to the camera. In one em bodi- 
" S^nLJ h&JLtP^atc dj&rgn^ is sto red on the camera in 

a teflapocar y_buffer, such as volatile mem ory. 

At block 202, the camera API 62 closes the camera driver. 

30 This shuts down communication between the camera and the 
host system so that the firmware update is not interrupted. 
The camera API then signals the host application software 
that it is in the process of updating the firmware, as shown 
at block 204. The camera API begins to poll for the firmware 

35 to re-establish a connection with it. 

The firmware is made up of a boot block and a code block. 
The boot block, also called the bootloader, is not replaced 
when the firmware is replaced. Only the code block is 
replaced. The bootloader maintains the routine for updating 

40 the firmware. At block 206, the bootloader validates that the 
updated firmware image is error fi-ee. This can be performed 
by generating a checksum, for example. The bootloader then 
substitutes the updated firmware image for the old (installed) 
firmware, as shown at block 208. In one embodiment, this is 

45 performed by transferring the firmware image from volatile 
memory into nonvolatile memory. The bootloader then 
either causes a reset, or it jumps to the start of the bootloader 
to initiate the newly updated firmware, as shown at block 
210. This causes the bootloader to restart, at which point the 

50 bootloader checks for errors in the updated firmware, as 
shown at block 212. If the checksum is correct, then the 
firmware in the code block is executed, as shown at block 
214 and 218. 

If the checksum is incorrect, the bootloader re-establishes 
55 a connection with the host system and moves to a waiting 
state, as shown at block 216. In this waiting state, the camera 
API may get status from the bootloader to determine 
whether the new firmware image was loaded properly into 
the code block, or whether there was a problem, and the 
60 bootloader is in the waiting state. The camera API may 
attempt another update of the firmware. 

Proceeding from block 218, once the firmware is able to 
restart with a correct checksum on its code block, then the 
firmware can establish a connection with the host system. 
65 The camera API will detect from its polling that the camera 
is connected at block 220. The camera API can then re-open 
the camera driver and perform accesses to the camera. 
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FIG. 8 shows ooe embodiment of a slate transition dia- 
gram of the firmware boot process. The state transition 
diagram is divided into ^oLblork- .slatf.s nn Ihr. lf.fi hand 
sidfiuOLlhe FIG. 8 and a code, block s tate o n the right hand 
side of FIG. j^^At state 300; a res erinitializcs the camera 
hard>vare. This may include resetting registers and/or turn- 
ing off certain units of the camera, so that the camera is in 
a known state. From state 300, there is a transition to state 
302, at which the code block is checked. In one embodiment, 
a checksum is performed on the code block. If the checksum 
passes, then the instructions in the code block are executed, 
as shown at state 304. ThefirmwareJnJhe_cjxleJ3locki^ 
to establish a connection with the host system and hand les 
\larfous^coDnmand&~i&ce ivedfirom tbs _ hpst system. I f the 
firmwafe^'th c code block detects that the hc^t system has 
isstt ^ a download comma nd.J hcn the state transitions ^ to 
state 306^ at which the camera hardware jmtjflliTed intn a 
knowrustale-. For example, the sensor and strobe may be 
turned off, and the DRAM may be turned on. In one 
embodiment, the camera-hardwaxe is turned off when not in 
use in order to save power. The state transitions to block.3p8, 
a t which the updated firmware code is received from the h ost 
s ystem . Thejip_dated,firmware_codcLisjempQrarily in 
DR AM in .-one~embodi ment If th ere is a communication 
problem at state 308, then there is a transition to waiting 
state 310. At waiting state 310, the boot block waits for a 
command from the host system. 

From state 302, if the checksum fails, then there is also a 
transition to waiting state 310. At waiting state 310, the boot 
block waits for a command from the host system. The host 
system, for example, may request status information from 
the boot block . When the host sysTem realizes that the boot 
BTock is in waiting state 310, the host system can issue 
another download command, which results in a transition 
back to state 308. 

From state 308, if the fir mware image is^ downloaded 
without errors, then there is a transition to state 320, at which 
the code that was downloaded is checked for errors. In one 
embodiment a checksum is performed. If the checksum fails, 
then the boot block returns to waiting state 310. If the 
checksum passes, then the state transitions to block 322, at 
which the code block is erased. Subsequently, the code block 
is re-programmed in state 324. From stale 324, there is a 
transition back to state 300 at which the camera hardware is 
re-initialized and the state transition diagram restarts as 
previously described. 

FIG. 9 shows a diagram of an exemplary nonvolatile 
memory 400. In one embodiment, the nonvolatile memory is 
a flash memory. In one embodiment, the boot block 402 and 
code block 404 are stored in the flash memory, and the boot 
block is locked so that it is not overwritten. The code block 
is re-programmable. 

In one embodiment, the nonvolatile memory also stores 
one or more imaging tables 406. The imaging tables may 
include information associated with the configuration of the 
camera. 

In one embodiment, the fo flowing imaging tables are 
stored in the flash memory. 

1) dead pixel table 

2) encoder table 

3) exposure table 

4) compander table 

5) color correction tables 

The imaging tables a flow for processing of an image in 
the camera. For exampleTtHe dead pixel table may include 
information on particular pixels of the camera which do not 
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work properly The dead pixel table may be determined 
during manufacturing testing, for example. Alternatively, a 
camera may be able to determine dead pixels dynamicaUy. 
The dead pixel table allows for interpolation using neigh- 

5 boring pixels to compensate for the defective pixels. 

Similarly, the other imaging tables aUow manipulation of 
imaging data. For example, the encoder table may specify 
particular values used for encoding or compressing an 
image. Exposure tables may include information on expo- 
sure time, gain, strobe, use and intensity. The companding 
table may include information used to map data from a bit 
representation using a first number of bits to a bit represen- 
tation using a smaUer number of bits. The color correction 
tables may be used to correct colors. 

In one embodiment, the imaging tables include values that 

1^ are associated with a particular flluminant. For example, the 
imaging tables may include different values corresponding 
to the capture of an image in either sunhght, fluorescent 
lighting, or tungsten bulb lighting. 

The imaging tables may be stored into the nonvolatile 

20 memory 400 during manufacturing, but may be updated 
later by the firmware. In one embodiment, the firmware is 
able to delete imaging tables in the nonvolatile memory and 
transfer new imaging tables from the host system to the 
nonvolatile memory of the camera. The firmware receives 

25 commands from the host system which indicates whether a 
table is to be transferred to the camera, or whether an 
imaging table is to be deleted. 

In one embodiment, because some nonvolatile memories 
(e.g., some flash memories) are not able to both read from 

^0 the nonvolatile memory and write to the nonvolatile memory 
at the same time, a DRAM is used to temporarily store code 
from the nonvolatile memory. The firmware copies a portion 
of its code to the DRIJlM, then transfers execution to the 
DRAM. A microoontrolUer executing instructions out of the 

35 DRAM is able to then write the new imaging tables to the 
nonvolatile memory. Execution is subsequenfly transferred 
back to the code section of the nonvolatile piemory. 

Tables 1 and 2 are used to show examples of how various 
versions of interfaces, firmware, and camera APIs on dif- 

40 ferent cameras and personal computers (PCs) may interre- 
late. Table 1 indicates a configuration table stored in a first 
camera API (CAMAPI #400). Table 2 indicates a configu- 
ration table stored in a second camera API (CAM API #420). 
Some examples of various embodiments iisin g~thc"confi gu- 

45 ration information stored in these tables^wiU.help^to illus- 
trate. 



TABLE 1 



50 






Firmware Version/ 


Interface Idcntifici ^ 


Hardware Version ^ 


Firmware Image 




0x0101 


1.00 


l.OQ/Filename 3 






1.01 


1.02/Fileaame 4 






1.02 


1,07/Filcnamc 5 


55 


0x0202 


2.00 


l.oa/Filename 6 


TABLE 2 


60 


tntcrfiace Wcntifier 


Hardware Version 


Firmware Version 




0x0303 


3.00 


1.09/Filename 8 




3.01 


1.09 


Filename 8 




3.02 


2.18 


Filename 12 




0x0404 


4.00 


3.08 Filename 13 



65 

Example 1: Assume that two users, A and B, have the 
same version of host application software and firmware 
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versions. Let the software version be 1.0 which creates available, the process continues at block 510. At block 510, 

CAMAPl #400 having the table of identifiers shown in Table the camera API sends a message to the host application 

1. The interface identifier is 0x0101, and the firmware software indicating that a camera is available. The host 

version is 1.00. Next, user A receives an upgrade and appUcation software requests that the camera driver be open 

updates his host application software to version 1.02, which 5 at block 512. The camera API responds by opening the 

has the same interface (0x0101). camera driver, as shown at block 514. The process of 

After the host application software is upgraded, the first opening a driver means establishing a connection between 

time that user A tries to access the camera, the camera API the camera API and the camera driver. The firmware update 

62 will detect an incompatible version of firmware. It will process, as previously described, occurs at this point, 

trigger the firmware to be updated automatically, as was At block 516, the host application software requests that 

previously described. images are transferred from the camera to the host system. 

Subsequently, assume that user B (who still has finnware The camera API responds by transferring image information 

version 1.00 on his camera) brings his camera to A's PC and from the camera to the host application software at block 

plugs it in. The camera API on A*s PC will again detect the 518. Image information may include image pixel data as 

firmware and software versions. The camera API will update well as other information, such as color palette information, 

the firmware on B*s camera to 1.02. B's camera will now compression information, orientation of the image, and so 

have a different firmware (1.02) than the host software on forth. The flowchart terminates at block 520. 

B's PC. When B takes his camera back to B*s PC, the FIG. 11 shows a flowchart of one embodiment of the 

camera API 62 wiU have no knowledge of the firmware process of detecting that an imaging device such as a camera 

version 1.02. The camera API 62 will transfer the firmware is attached to a host system. The flowchart starts at block 

image version 1.00 to B's camera. Thus, B's camera is 20 600. It continues at block 602, in which the operating system 

restored to its original firmware so that it can communicate determines if a camera is available. This may be done with 

with the software on B's PC. the aid of a port driver such as a USB driver. If the camera 

The firmware update is uransparent to B. B is able to use is not available, the process returns to block 602. If a camera 

his camera on either A's updated system or B's system with is available at block 604, the process continues at block 606 

older host application software. 25 at which the operating system loads the camera driver. 

ample 2: Assume that A has firmware version 1.00, In one embodiment, an operating system such as Win- 
interface 0x0101, and B has firmware version 1,08, interface dows 98 is used by the host system. Windows 98 allows the 
0x0202. B cannot use A's PC unlessAupgrades her software driver to signal the operating system of the camera being 
to recognize the new interface 0x0202. If B's PC uses the connected to the host system (the connection event), as 
camera API including all revisions shown in Table 1, then 30 shown by block 608. The operating system then opens the 
B's PC can be used with either A's camera or B's camera. applications that are registered with the connection event. In 
Example 3: If user A has firmware version 1.0 and uses this case, the host application software for the camera is 
CAMAPl #400 as shown in Table 1, and user B has firmware initiated, as shown at block 610, The flowchart then contin- 
version 3.0 and uses CAMAPl #420, as ^own in Table 2, ues with the flowchart of FIG. 10. 

then a PC must have both versions of software that interface 35 If the operating system does not provide a way of opening 

with the separate interfaces to the cameras in order to access an application based on the coimection event, an alternate 

both cameras. embodiment may use a " service" instead of the steps shown 

In one embodiment, the interfaces have unique interface by blocks 608 and 610. The service is installed by the user 
identifiers. One example of an interface is the TWAIN and is initiated on the host system automatically when the 
interface, which describes to an imaging application how to 40 host system boots up. The service opens the host application 
go about acquiring images ft'om a scanner or other digital software when a camera is detected. In one embodiment, the 
imaging devices. The current version of TWAIN is 1.7. service uses the camera API to determine if the camera is 
TWAIN is maintained by a standards group made up of available. Thus, the service acts as a mini-host application in 
several industry participants. More information on TWAIN a manner similar to that shown in FIG. 10. However, the 
is available through http://www.twain.org. Proprietary inter- 45 service initiates the host appfication software when a con- 
faces may also be used. For example, DLLs supporting a nection to the camera driver is established. The host appli- 
particular application program so that the application pro- cation then establishes its own connection to the camera 
gram has the ability to transfer and delete images ft'om the driver to transfer images from the camera, 
imaging device may be supported. In one embodiment, the host application software 60 and 

The hardware identifier specifies hardware changes, for so the camera driver 44 are shipped with the camera 10. The 
example, a stepper motor may be added to the imaging host apphcation software 60 and camera driver 44 may be 
device. Firmware releases may be set up to track minor and shipped via floppy disk or CD-ROM. Alternatively, the host 
major changes. For example, a minor change may be a bug apphcation software 60 and camera driver 44 can be down- 
fix or enhancement. A major change may be the addition of loaded via the World Wide Web. The host appUcation 
new hardware. 55 software 60 and camera driver 44 are installed to a storage 

FIG. 10 shows a flowchart of one embodiment of the medium on the host system, such as a hard disk, dynamic 

process of initializing the host application software to estab- random access memory (DRAM), static random access 

lish a communication with an imaging device. In this memory (SRAM), or flash memory, 

disclosed embodiment, the imaging device is a camera, and In the foregoing specification, the invention has been 

the host system is a personal computer. The flowchart begins 60 described with reference to specific exemplary embodiments 

at block 500. The process continues at block 502, at which thereof It will, towever be evident to someone having the 

the host application software creates a camera API. The benefit of this disclosure, that various modifications and 

camera API loads a DLL that may be operating system changes may be made thereto without departing from the 

dependent at block 504. At block 506, the camera API broader spirit and scope of the invention as set forth in the 

determines if a camera is available. 65 appended clainos. The specification and drawings are. 

At block 508, if a camera is not available, then the accordingly, to be regarded in an iQustrative rather than a 

flowchart returns to block 506. However, if a camera is restrictive sense. 
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What is claimed is: 

1. A method of updating firmware on an imaging device, 
the method comprising: 

upon establishing a connection between the imaging 
device and a host system, automatically detecting if a 
firmware version on the imaging device matches a 
firmware version on the host system; 

if the firmware version on the imaging device does not 
match, 

updating the firmware on the imaging device automati- 
cally with firmware located on the host system, and 
executi ng the updated fim3ware;^a nd 
if the firmware version on the imaging device matches, 
executing the firmware on the imaging device. 

2. The method of claim 1, wherein the step of detecting 
further comprises: 

receiving device interface information from the imaging 
device; and 

comparing the device interface information with interface 
information stored on the host system. 

3. The method of claim 1, wherein the step of updating 
further comprises: 

loading the firmware from the host system to a buffer 

memory on the imaging device; 
checking for errors in the loaded firmware; and 
refreshing the firmware on the imaging device with the 

loaded firmware if the loaded firmware is error free. 

4. The method of claim 3, wherein the step of updating is 
repeated if the loaded firmware is not error free. 

5. The method of claim 1, wherein the step of updating is 
performed if the firmware version on the imaging device is 
an earlier version of the firmware than the firmware version 
on the host system. 

6. The method of claim 1 further comprising: 
loading at least one configuration table into the imaging 

device from the host system. 

7. The method of claim 6, wherein the at least one 
configuration table are used to manipulate imaging data on 
the imaging device. 

8. The method of claim 1 wherein the step of executing 
the updated firmware is performed by initiating a reset to the 
beginning of a bootloader. 

9. A system comprising: 
a processor; 

a storage medium storing instructions which when 
executed by the processor cause the processor to: 
detect if a connection is established between an imag- 
ing device and a configuration system; 
if a connection is established, detect if a firmware 
version on the imaging device matches a firmware 
version on the configuration system; 
if the firmware version on the imaging device does not 
match, update the firmware on the imaging device 
automatically with firmware from the configuration 
system, and execute the updated firmware; and 
if the firmware version on the imaging device matches, 
execute the firmware on the imaging device. 

10. The system of claim 9, wherein the step of detecting 
comprises: 

receiving device interface information from the imaging 
device; and 

comparing the device interface information with interface 
information stored on the configuration system. 

11. The system of claim 9, wherein the step of updating 
further comprises: 
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loading at least one configuration table into the imaging 
device from the configuration system. 

12. The system of claim 11, wherein the at lest one 
configuration table are used to manipulate imaging data on 
the imaging device. 

13. A computer-readable medium containing executable 
instructions which, when executed in a processing system, 
causes the processing system to update the firmware on an 
imaging device by: 

detecting if a connection is established between an imag- 
ing device and a host system; 

if a connection is established, detecting if a firmware 
version on the imaging device matches a firmware 
version on the host system; 

if the firmware version on the imaging device does not 
match, updating the firmware on the imaging device 
automatically with firmware from the host system, and 
executing the updated firmware; and 

if the firmware version on the imaging device matches, 
executing the firmware on the imaging device. 

14. The medium of claim 13, wherein detecting if a 
firmware version on an imaging device matches a firmware 
version on a host system further comprises: 

receiving device interface information from the imaging 
device; and 

compating the devine interface information with interface 
information stored on the host system. 

15. The medium of claim 13 further comprising: 
loading at least one configuration table into the imaging 

device from the host system. 

16. The medium of claim 15, wherein the at least one 
configuration table are used to manipulate imaging data on 
the imaging device . 

17. The medium of claim 13, wherein the step of updating 
further comprises: 

loading the firmware from the host system to a bufier 

memory on the imaging device; 
checking for errors in the loaded firmware in the buffer 

memory; and 

refreshing the firmware on the imaging device with the 
loaded firmware in the buffer memory if the loaded 
firmware is error free. 

18. The medium of claim 17, wherein the step of updating 
is performed if the firmware version on the imaging device 
is an earlier version of the firmware than the firmware 
version on the host system. 

19. A method of updating firmware on a camera, the 
method comprising: 

connecting the camera to a host system; 

detecting if a firmware version on the camera matches a 

firmware version on the host system; 

if the firmware version on the camera does not match, 
updating the firmware on the camera automatically with 

firmware from the host system, and 
executing the updated firmware; and if the firmware 

version on the camera matches, 
executing the firmware on the camera. 

20. The method of claim 19, wherein the step of detecting 
further comprises: 

receiving device interface information from the camera; 
and 

comparing the device interface information with interface 
information stored on the host system. 
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21. The method of daim 19 further comprising: 
loading at least one configuration table into the camera 

from the host system. 

22. The method of claim 21, wherein the at least one 
configuration table are used to manipulate imaging data on 
the imaging device. 

23. A system for updating firmware on an imaging device 
comprising: 

means for detecting if a firmware version on the imaging 
device matches a firmware version on a host system; 

if the firmware version on the imaging device does not 
match, 

means for updating the firmware on the imaging device 
automatically with firmware from the host system, 
and 

means for executing the updated firmware; and if the 
firmware version on the imaging device matches, 

means for executing the firmware on the imaging 
device, 

24. A method of updating firmware on an imaging device, 
the method comprising: 

sending a firmware version on the imaging device to a 
host system in response to a request from the host 
system; 

if the host system transfers firmware to the imaging 
device, 

updating the firmware on the imaging device automati- 
cally with the firmware from the host system, and 
executing the updated firmware; and 
if the host system does not transfer firmware, 
executing the firmware on the imaging device. 

25. The method of claim 24, wherein the step of updating 
further comprises: 

loading the firmware from the host system to a buflfer 
memory; checking for errors in the loaded firmware; 
and 

refreshing the firmware with the loaded firmware if the 
loaded firmware is error free, 

26. The method of claim 25, wherein the step of updating 
is repeated if the loaded firmware is not error free. 
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27. The method of claim 24 further comprising: 
loading at least one configuration table into the imaging 

device from the host system. 

28. The method of claim 27 wherein the at lest one 
configuration table are used to manipulate imaging data on 
the imaging device. 

29. A system for updating firmware on an imaging device 
comprising: 

means for sending a firmware version on the imaging 
device to a host system in response to a request from 
the host system; 

if the host system transfers firmware to the imaging 
device, 

means for updating the firmware on the imaging device 
automatically with the firmware from the host 
system, and 

means for executing the updated firmware; and 
if the host system does not transfer firmware, means for 
executing the firmware on the imaging device. 

30. A system for updating firmware on an imaging device 
comprising: 

a firmware version on the imaging device; and 
updating logic within a host system configured to update 
the firmware on the imaging device automatically with 
firmware from a host system if the firmware version on 
the imaging device does not match a firmware version 
on the host system . 

31. The system of claim 30 further comprising: 

a buffer memory on the imaging device for receiving 

firmware from the host system; and 
a bootloader on the imaging device configured to check 

for errors in the firmware received by the buffer 

memory from the host system. 

32. The system of claim 31 wherein the updating logic 
automatically updates the firmware on the imaging device 
upon establishing a connection between the imaging device 
and the host system. 
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